SOFTWARE TESTING OF ATTITUDE AND 

ORBJT CONTROL COMPUTER (AOCC) 

OF iNSAT-2E 



S. Udupo, FitzgeraldJ.Archibald, MM. Nayak, S.LaPfshmi, 
V.K. Agrawal, N.K. Kflafik 

Contro! Systems Group 
fSFlO SatelUte Ccntfs 
Bsngak}f& ~ 560 Oil 



9y 



Abstract '^ 

Spacecraft Attitude and Orbit Control System & a mission crrtical rsai tirne 
smbeddijd system, The special characteristics of real time systems {time - 
tfependent, asynchnoncusji offer major challenges when testing is to be 
conductecf. In many sJtuations, test data provided, when a reaf time system is in 
one state will result in proper processing, wfiite the same data provided when the 
system is in a different state may lead to error. To validate certain type of 
computation bound equ^tiors, we may have to perform e^^au stive testing for 
ev$n more than 90^000 iteralions. TliFs paf>er brings out the approach and 
experiences in lesling the onboard soflwam. 

1. INTRODUCTION 

The INS AT 2E is an operational system designed and developed for 
teJecommunication, television and radio broadcasting and moteoroiogical data 
cofiectEon and utiliiation. The various systems in the spacecraft are stnjctures, 
prt^ulsion, communication payload, Alti'tude £ Ort>it Control System(AOCS), 
Tefemef^A Teic-command (TTC), Power System, cfepioyment mechanism and 
thermaF system 

AOCS uses the 3-axts body stabilized momentum biased system with 
momontum/reactlon wheel lo provide a stable platform for communication and 
meteorological applLcations, The AOCS provides the capabiJIty of tho 3-axis 
attitude control, TTie AOCS consists of MIL-STD-1750A based Attftude &. Orbit 
Control CompiJter(AOCC} which receives attitude data from sensors, computes 
the necessary control toque commands and outputs to tfie actuators. The 
different modes of opcrati-on are iaunchor phase, transfer orbit operations (SoutF^ 
Sun Acquisition, Transfer Orbit Earth Acquisition, Liquid Apogeo Motor mode), 
synchronous orbit operations (Synchronous Ortit East W&sf Sun Acquisition, 
Synchronous Orbit Earth Acquisition, On-Orbit, Station Keeping) & safe mode, in 
addition to the control iuncti-ons, as mentioned above, AOCC also performs 
related command & monitoring functions, The notable feature of an embedded 
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system is thai there is a large degree of coupling between hardware and 
software, so is tho case of the spaciecraft onboard coinputfer. Sound 
methodologies are adopted for developing software for this embedded system. 
Details of software development meUiodology is given in ref [ 1][4]. Herej we are 
giving only an outline of the davelopmenl. In the requirement phase, ggftwane 
requirements are gnnc rated baaed on the spacecraft requirements and" control 
requirements. In design pliase, the structure of softwarB is designed, whicfi 
includes module idcntLficalion, module iriterface dtjsign and associated reviews, 
in devetppmenl pfiase, code generation and review of codes ^s oarried out based 
on cettain guidelines- in testing phase, all efforts are at detecting software errors 
by devising different methods and combinatiort of test vectors. This paper gives 
briefly description of testing philosoptiy, various methods available and emphasis 
on the testing rmethodology followed by illustrative examples. 

2, BACKGROUND 

HeSiabitity of a software depends upon the methodology adopted for 
software development. In any of the software melhod&logy. testing plays an 
important role. A good amount of testing improves the quality of Software by 
uncovering the software bugs and proves that software meets design 
specification and hence requirements. Particularly, the testing plays a very 
important measure for frie application like ours, where it is not posseble to repair 
the software and rt is mission critJcaJ. Any bug in the software may result in 
mission disaster, in fact, for a critical system, testing tai<C5 about 50% of the 
development timcj. As tine software becomes complex, the test procedure also 
becomes complex. According lo Glen Myers [ 5 ). the following rules serve as 
testing objective. 
(i) Testing is a precess of executing a pnogram with the intent of fmding an 

error. - - « - : -i--. 

(iij A good test ease is one that has a high probability of finding an as yet 

undiscovered error. - ;tii jj ■-.;•-'», 

(ill) A successful test is one that uncovers an as yet undiscovered error. 
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The representation of a testing process can be found in reJlS]. 

Based on the softwane configunatic-n and test conriguration teat esses are 
prepared. The system is then tested with these test cases. TTie resuits of these 
test cases are logged and arc evaluated based on the expected test results, 
The errors are then comacted. The observed errors can he used as a reliability 
pncdiction of the software, depending upon the reliability model. 

A systematic testing involves a systematic fest procedure at various fevefs 
of software developed. The testing has to be earned out at various levels of 
development, A lypicai software test stage configuration csn be found in ref [9). 
In this software classification, the software is -diivided into several stages. A 
software system Is di^yided into software subsystem, each subsystem is divided 
into software modules. Each of these software nnodules are in turn divided into 
pnocedure or function. The testing starts from the procedure level and ends at 
the system level . This testing process is Eteratrve. Ttie errors found at each 
stage is fed back to the previous stage for correction and retesting. A proper 
ctassifjcafien of each of the software component helps in fndepentfent testing at 
each stage. 

For an efficient testing of a compien system, proper test plan strategy is 
needed. In general, the testing process commences In parallel with the software 
development process. The test plan preparation starts with the system 
requirement phase itself. A typical test plan strategy linked with (he software 
development cycle can be found in ref J g]. 

In a more complex and very large system, drfferent test strategy may be 
used for different parts of the system. From the strategy view point, test vectors 
are designed in fJiree broad types; Top-down approach, bottom-up approach 
and thread testing [9 ]. "niese are briefly described here. 

In top-down testing method, testing begins at subsystem level with 
modules represented by stwbs. After all the subsystem are tested, modules are 
tested in the same way by representing the functions and procecfures with stubs. 
Finally, program components are replaced by the actual code and tested. In this 
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method, thD modules get tested as and when, they are developed, withoyl waiting 
for the lower levpl components to be developed- This method is very diftlcylt lo 
adopt for complex systems, as the stutj development consumes mgne time. 

In bottom-up testing me&iod, lower level modules are tested 1itst and 
then higher level modules are tested in upward manner. Test drivers are to be 
written to stmulate the component ertvironment. 

In thread testing method, eacSi process is tested Individually by top- 
down/ boltom-up methods. This is largely adopted for systems, where the 
processes are event based aod have time dependent interaction between 

processes, 

ttie success of testing largely depends upon the suitability of test cases, 
Our obiectivq in designing lest cases is to uncover different emjrs with a minimal 
time and efforts, Different criteria are used for test case generation at different 
levels of testing. System level testing ard acceptance level testing are 
concerned witb functional and system specification valid ation/verification, 
whereas procedure, module and subsystems level are concerned with detection 
of tiidden defects. It is often verj^ time constjming to test a3l possible combination 
of paths. As there may not be a definite rule, cenain heuristics are nomnally 
used in selection of test cases. For estampie, we should check all types of 
computation, rnaximum and minimum value of input variable, gvoifiow and 
underflow expected conditions, counter loops etc. TTie test case generation is 
also linked with the fdnd of testing. 
Testing is classified as 

{]) white box testing and 

(ii] black box testing [5J 

Wfnite box testing is applied to the early stages of software development. 
The method uses tJie control structure of the procedure design to derive the lest 
cases. Here ttic main emphasis on the basts patfi testing and control stnjcture 

testing. 

Test cases of black box testtrtg are designed with the knowledge of 

product specification. The tests ane conducted to demonstrate the functions of 
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the product, that they meet the specif icatf&ns. TTie test cases ar$ used to 
demonstrate that software functions are operational, input is properly accepted, 
output is cornectly producsd and tlie integrity of esttemai informatior i$ 
maintained- It ctoes not examine the internal logical structure oi the software 
and finds incorrect or missing functions, intorface errors, errors in data structure 
or external data base access, performance errors, initialization and termirialion 
errors, etc. There are many methods to efficiently carry out the blacl^ box testing 

Based on the above background, we have carriecf out the testing 

on the AOCC software in different stages. 

I' : 

3. AOCC SOFTWARE Testing : 

"Extensive testing oJ the software" is taken 33 a major step to improve the 
reliability of AOCC softwans. In this procesSj we fodow similar steps as 
mentioned in the previous section. 
3,1 Unit Testing ; 

During unit testing, we concentrate about tfie connect implementation of 
soun^e code, using the principle of white box testing. Each unit or 
procedure is tested individually ensuring ttiat it functions properly as a 
unit. All paths are covered In detail. Flow, logics and computational 
checks are also performed. Following gives more details on each of the 
testing. 

a) Module Interface : 

The units are integrated to module, therefore checks are done to 
validate tJie [/P and O^P interface cff e^ch unit, This ensures that we 
encounter no problem at the module development, 

b] Data Structure : 

Data structures are e>amined to ensure that d^ta are stored 
temporarily and maintain its integrity, during ^|| the Steps of program 
execution. 



?7 



c) Boundary conditions : 

BoLirdajy condifions are checked to ensure the proper execution of 
unrt under qxtromc limit conditions. Al! the restrictions on the units are 
checked and reoonded. 

d) Independent path : 

The major importance at unit test Is to veriiy ttie operation of all the 
path$. Though, it is extreme!/ difficult to cover all possible seciuences 
of the paths, efforts are made to the maximum ertcnt. Bevond this 
stage of testing, all the &(tot handiinig paths are also tested. ' "■" 

e) Computation Checks: 

Another important check we are canr/irg out at this stage Is that of 
computation aspects. Different precision's jif ariEhmelic are used in 
practice. Also the truncational error ana to be verified. This is 
achieved by comparing tho results at various iterations in steps oF say 

(1,10, too, tOOO ) for the units from the simulation to the actual 

reajis^ttcn, 
3.2 IVfoduTe Testing : 

The units are introduced into modules and all the paths of a modute are 
tested as it was done in unit testing, f-ictvi the eomputalion are dof*e at 
higher level Again like the unit test, ttie computation checks are 

perfonriDd for 1,10, 100, 1000, iterations. The number of 

computational steps are decided by the structure of the co-mputalional 
algorithm. The objective of this test is to continue the test until all 
variables of t^e control equation are e>j3TCised lo its full dynamic range. 
Somelimes it may be necessary to derive fecial initial conditions to 
achieve the objective. Most of the oortipulatjona! errors uncovered at thts 
stage. The execution time of the moduSe, worst, best case and average 
case are measured at the end of this testing, This step is necessary to 
integrate the modules and maintain their time line. 
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3.3 integration Testing: 

This, is done aftpr intcgraitLon of several modules to ittttf\ A SUbsyBtom 
program. At this stags, all the module ititerfaces, escecution time and ttie niodule 
vierificatigr ans performed. The integration of moduie is done in bottom up 
approach. The timing measurement are also perfom^cd. As a thumb mie, 25^ 
time margin expected at this level O'f liming evaluation. •• ■, 

3.4 System Testing 

After the sut>sv?*eni test, the software subsysiem ai^e integraied lo form a 
•full nyttem. Several tests are conducted at this level and are discussed below. 

Initially performance tests are performed, lo verify performapice of the 
system to meet the specification, Tfie system is than subjected to stress teat, 
where the perforniance of the software is observecE with out-of-bouncT input value. 
The software should rtol misbehave in sutti condiHons also. Then security 
testing is perfonriBd to validate the protection mechanism buill inlo a system and 
validate the improper peneiratioin in software area, Finally, recovery testing is 
perfonned to verify the software recovery from the fault conditions, 

Unit level teslingn Moduie & (ntegrated testing are carried out using our 
development environment. During initial stages of software development IBM RS 
6000 work station witfi development tool which Is designed En house were used 
as tofaS software development platform. The development tool is specially used 
for ttte timing testing of time and module piaccmont. in our development 
environment the routine gels l/P from the script file generated by the debugger. 
Since the debuEiger does not support fO operations, it is difficult to tamper the 
actual routine for performing lO operations. 

3.5 Bench Level Test: 

Here, the AOCC is interfaced with Test System as shown in fig,1 . The test 
system simulates all the inputs that arc required by AOCC. The interface circuits 
wiEl be same as actual system interface in spaceoraft. 

The Bench Test will be carried out as per the test document. This will be a 
black box testing. All the functions will be validated and verified here. Each test 
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case will be fed and test results will bo tabulated. All the probEems cncouniered 
will be recorded and will go through test result review commitlee. Baaed on the 
ruviBw committee recommendation, further action will be taken. Once the system 
has undergone tbe bench level tests^ the test engineer will certify the pack^e 
performance. 

3.6 Hardware-lri-Loop Simulatiort(HlLS) Test: 

In HILS test, the AOCC is inlorfaced with aotua! sensor and the actuator 

in loop . A simulator program simulates XhQ dynamics of the spacecraft. The 
simulator takes Ihe torque curtput from the AOCC and provides the necessary 
driv0 signal to servo table to get the required disturbance. The sensor will be 
mounted on servo & will provide the errors, which i^ road by the AOCC and 
response wiiii mmo in the form of torque. Fig. 2 shows all the ei^monts of the 
HILS set up. Here, AOCC'-s dynamic behavior are verified. 

3.7 Envlrornnental Test: 

The AOCC undergoes the following environmental teals after the HILS 
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1, Therm ovac test: - The AOCC & spacecraft is subjected to various 
temperature under vacuum to study how it affects the varioiis 
subsystems and also to monitor the spacecraft's control mechanism 
under these conditions. 

2, Vibration test: - The health of various components are monitored lo 
find in which v;ay the vibration thqt occurs especially during the launch 
affects the ADCG S spacecraft. 

3, EMI/EMC test- This test will be conducted to verify the satisfajctory 
periormanpe of the AOCC in a radiation erwironment This will be 
conducted only it the package is new & the design is new. EMI spikes 
will bo introduced both in supply line as well as signal lines and system 
performance wilt bo verified. 
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4. EXAMPLES 

We presenf here some of the examples of vanous t&sEing stages, 

4.1 Earth Scnsor(ES) data processing: 

We take an example of ES data processing routine shown in fig 3- The 
purpose of this software routine is to read the ES data in ACXX and then 
process it foe tlie use of contra Der. The unit test is pefformed by identifying its 
paths. Each of Jhe operations are identified by number and thon hy using a 
sequence of liiese numbers, a fiow graph is prepared as shown in fig.4 . Tlncsnc 
eKisJ two paths named 1-2-3- 6- 7- S and 1-2-4-5-0-7-8. Ttie first 
palli tesls the data ready false condition ancf the second path tests Hie data 
neady true condition, Tliis is arr iiJustrative exampie. For more complex saftwaren 
the-re may be many palhs also. 

4.2 QuartEmion[Q) proccssfng: 

We present here, another e/ampie of Q computation shown in fig S. if is a 
computation intensive routine. The flow grapii of She routine is shown in fig. 6. 
El has two paths, in path 1 - 2 - 5, no computations are done. Therefore, the 
computational vaiue of Q1,Q2,03,Q4 and q^,<i2,(^3,^4 are unaffected, For the 
path 1 - 2 - 3 - 4 - 5, the O's and q'a are domputad at vailouE iterations and the 
resuHs are tabufated in a t^bfe. The computational equation a the output 
tabulation format are given in tabie - 1 . 

Here, the computed data are compared at different steps with simulation 
resufts. 

4.3 South Sun Acquisition (SS A) Module: 

We lake another exam pie of South Sun Acquisition mode, where the 
spacecraft is oriented such that its south face is pointed towards sun. Details of 
this mode may be found in [1]. Here, for the sake of understanding (he testing 
aspect, ttie flow chart is given in fig, 7 and ftow chart of ono of the modules of 
SSA processing is given in fig 7.1. This subsystem is tested for performing 
module & integratic^ testing. Each fiow graph is a rrtodule or combination ot 
modules. Some of (he flow graphs & the paths are shown in fig. 8, 6.1. It is 
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presented in a lop down way. At the top level, integration testing is perfomned at 
ieveJ down - moduJe level and unit level testing are peri ormetL 
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5. EXPERIENCES 

Some of the problems that wene detected during th& various stages of testing 
of I NSAT - 2 E and correcied are listed below. 1 

■ The following were detected and comected during the initial s/w testing : 
During computer sirnulation, it was detected that ttiere existed a 
matching prablcm due to the compiEor rounding off instead of 
expected truncation. 

In &ne of the lit>rary modules caJled TEST-BIT, the log-leal AN Ding 
gf ^cpr^^^igns werG resulting in inqe-n'ect outputs j 

Due to improper assembler directive, some programs were 
incomcctly allocated to RAM instead of PROM 
Due to some mismatch t>f the requirement specification , the 
relative Q computation was done every 1 Si th cycle instead of every 
150 cycles. This wpg found during simulation 
* The following were detected and corrected during the bencb level testing; 
During initial bench level test, it was found that there was floating 
point truncation error 

There was use of incorrect variables in the tacho hysterists. This 
was detected during cede walk-through 
The flap timing requirennent was not met & the placement of 
module was changed 1 

The potarity check for SADA(Solar Anay Drive Assembly) direction 
bit leversal was not correcl due to improper specification ^ 

Gain pointer updats was done wrongly in Telecommand processing 
It was found that floating point lo ir^teger conversion resulted in 
overflow 
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Du-e to inhibit duration, inconraot updates w&r& ctsorv^d for the 

'" * ' "' whe^l spiked 

(3. CONGLUStOM ' -q^f» ,':■ .1. ; o 

This paper prGsenfe testing aspect of the AOCC sofjware. The testing is 
performed in several steps. Such a kind of exhaustive testing is necessary for ih 
critical application. Most of the computational and logical enrorg are uncovened by 
this lesling. Each stage of tesling needs a thorough analysis of software and 
proper sequence of lest case generation is expected. tKSAT - 2 E AOCC 
software testing is perfomed in this mariner. No major errors have been found 

erthei" at ground or at on-board, 

' '.■' ■ 
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TABLE - 1 



Computational Equations for Q Processing: 






= Constant * Incremental Yaw Angle 
= Constant * Incremental Roll Angle 
= Constant * Incremental Pitch Angle 



= 1,O-3,33E-0T ' tq-. 
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Output TabLiiation Format 




























Step No 


Simulated q's 
q1 q2 q3 q4 


Observed q's 
q1 q2 q3 q4 


Simulated Q's 

Q1 Q2 Q3 Q4 


ObaeivtdQ's 
Q1 Q2Q3Q4 
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HOST 

(DEC ALPHA} 
DSF 
™. TC 
OPEJJ LOOP 
TESTIMG 
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r=c> 
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EtHERNEl 



(DEC ALPHA) 
H1L5 

DYNAMICS 
SIMULATION 
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DOS 
3B6/455 BASED 



STANDARD GPIB 
INSTHUIiiENT^ 



OSCILLOSCOPE 
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POWER SUPPLY 
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H-1. H-2. H-2' & H-3 ONE TO ONE HARNESS 



pf^.] TEST SYSTEM SETUP 
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Rj^ FS DATA PROCESSING 



C DIGITAL DATA STORING ) 



'■.'_• r"* 



N 




SET ES D^TA READY 

FLAG = FALSE 



-•v; 



* i- 



* SET ES DATA READY 

FLAG = TKUE 

* RESET DATA READY 

FUP - FLOP 



STORE ES ROLL & PITCH DATA. 

UPDATE TW 



STORE DTG INCREMENTAL ANGLE 
LOCATIONS FROM BUFFER LOCATIONS 



] 



STORE DCS DATA FROM 
BUFFER LOCATIONS 



(^ RETTJRN ) 
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Ff^-^ Flow graph notation of EE data processing 
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f Fj,6 Flow graph notation of Quartcrnion propagation 
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